This PR refactors how cycles changes to balance and metrics are happening via the SystemState. Specifically, it more clearly separates adding/removing cycles to the balance from refunding/consuming cycles which on top of the balance updates the respective consumed metrics as well.

The idea is to separate in two pairs of APIs that will be responsible for each type of update:

fn add_cycles(amount: Cycles);
fn remove_cycles(amount: Cycles);

to handle balance only changes while

fn refund_cycles<T>(prepayment: CompoundCycles<T>, refund: CompoundCycles<T>);
fn consume_cycles<T>(amount: CompoundCycles<T>);

will handle metrics being updated as well.

This change has a two fold benefit.

On one hand, it allows us to perform direct updates to balance (e.g. when depositing cycles or attaching cycles in calls) without having to construct CompoundCycles<NonConsumed> which was a somewhat hacky way to say "no need to update metrics". In fact, after this change, NonConsumed can be completely removed from CyclesUseCases. This allows for some simplification in call sites where they don't need to deal with CompoundCycles or doing so incurs unnecessary extra work.

On the other, it allows us to require a prepayment for refunding cycles which would be very helpful in a follow up where a metric which acts as a counter will be introduced and the amount consumed will need to be computed based on prepayment and refund. This way the call sites that don't need or should not deal with prepayments (i.e. ones that need only add_cycles), they don't have to be exposed to any of this.

The meat of the changes are in SystemState while there are some updates in production code and tests to match the refined API. In many cases, it ends up in a simpler version of the code as a bunch of CompoundCycles::new calls are eliminated or the cost schedule does not need to be piped through various calls.